Skip to content

Fix invalid dummy pubkey in send_to_route#4707

Merged
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom
valentinewallace:2026-06-fix-sendtoroute-dummy-pk
Jun 17, 2026
Merged

Fix invalid dummy pubkey in send_to_route#4707
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom
valentinewallace:2026-06-fix-sendtoroute-dummy-pk

Conversation

@valentinewallace

Copy link
Copy Markdown
Contributor

If a caller of send_payment_with_route provided a route with either no paths, or where the first path had 0 hops, the method would panic due to attempting to unwrap a dummy pubkey that was initialized with 32 bytes instead of the required 33.

Reported by Project Loupe.

If a caller of send_payment_with_route provided a route with either no paths,
or where the first path had 0 hops, the method would panic due to attempting to
unwrap a dummy pubkey that was initialized with 32 bytes instead of the
required 33.

Reported by Project Loupe.
@ldk-reviews-bot

ldk-reviews-bot commented Jun 17, 2026

Copy link
Copy Markdown

I've assigned @jkczyz as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

@ldk-claude-review-bot

Copy link
Copy Markdown
Collaborator

No issues found.

The fix is correct: a compressed secp256k1 public key requires 33 bytes (1-byte prefix + 32-byte x-coordinate). The original [2; 32] was only 32 bytes, causing PublicKey::from_slice to return Err and the subsequent .unwrap() to panic when a route had no paths or a first path with 0 hops. The replacement [2; 33] is a known-valid on-curve dummy pubkey used extensively throughout the codebase, so the .unwrap() is safe.

Cross-cutting note: the PR does not add a regression test exercising the empty-paths / 0-hops case that triggered the panic. Adding one would guard against future regressions, but this is optional and not a correctness issue.

@TheBlueMatt TheBlueMatt left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks

@TheBlueMatt TheBlueMatt merged commit 0b81d1b into lightningdevkit:main Jun 17, 2026
1 check passed
@TheBlueMatt

Copy link
Copy Markdown
Collaborator

Backported to 0.2 in #4706

@TheBlueMatt

Copy link
Copy Markdown
Collaborator

Backported to 0.1 in #4710.

TheBlueMatt added a commit that referenced this pull request Jun 19, 2026
v0.1.10 - Jun 18, 2026 - "Loupe de Loupe"

API Updates
===========

 * `DefaultMessageRouter` will now always generate blinded message paths that
   provide no privacy (where our node is the introduction node) for nodes with
   public channels. This works around an issue which will appear for any nodes
   with LND peers that enable onion messaging - such peers will refuse to
   forward BOLT 12 messages from unknown third parties, which most BOLT 12
   payers rely on today (#4647).
 * Explicit `amount_msats` of 0 is rejected in BOLT 12 `Offer`s; `OfferBuilder`
   now maps 0-amounts to an amount of `None` (#4324).

Bug Fixes
=========

 * Async `ChannelMonitorUpdate` persistence operations which complete, but are
   not marked as complete in a persisted `ChannelManager` prior to restart,
   followed immediately by a block connection and then another restart could
   result in some channel operations hanging leading for force-closures (#4377).
 * If an MPP payment is claimed but `ChannelMonitorUpdate`s for some parts are
   still being completed asynchronously, further channel updates (e.g.
   forwarding another payment) are pending and the node restarts, the channel
   could have become stuck (#4520).
 * The presence of unconfirmed transactions actually no longer causes
   `ElectrumSyncClient` to spuriously fail to sync (#4590).
 * `FilesystemStore::list_all_keys` will no longer fail if there are stale
   intermediate files lying around from a previous unclean shutdown (#4618).
 * When forwarding an HTLC while in a blinded path with proportional fees over
   200%, LDK will no longer spuriously allow a forward that pays us 1 msat too
   little in fees (#4697).
 * Fixed a rare case where a channel could get stuck on reconnect when using
   both async `ChannelMonitorUpdate` persistence and async signing (#4684).
 * `Event::PaymentSent::fee_paid_msat` is no longer `None` in cases where
   `ChannelManager::abandon_payment` was called before the payment ultimately
   completes anyway (#4651).
 * Syncing a `ChainMonitor` using the `Confirm` trait will no longer write some
   full `ChannelMonitor`s to disk several times per block (#4544).
 * `OMDomainResolver` now correctly accounts for failed queries when rate
   limiting, ensuring we continue to respond to queries after failures (#4591).
 * Calling `ChannelManager::send_payment_with_route` without a `route_params`
   and with an invalid `Route` will no longer panic (#4707).
 * `lightning-custom-message`'s handling of `peer_connected` events now ensures
   that sub-handlers will see a `peer_disconnected` event if a different
   sub-handler refused the connection by `Err`ing `peer_connected` (#4595).
 * Incomplete MPP keysend payments will no longer see their HTLCs held until
   expiry (#4558).
 * `InvoiceRequestBuilder` will no longer accept a `quantity` of `0` for a
   BOLT 12 `Offer`, allowing any quantity up to a bound (#4667).
 * `lightning-custom-message` handlers that return `Ok(None)` when asked to
   deserialize a message in their defined range no longer cause panics (#4709).
 * Several spurious debug assertions were fixed (#4537, #4618).

Security
========

0.1.10 fixes a sanitization issue and several denial-of-service vulnerabilities.
 * `Bolt11Invoice::recover_payee_pub_key` no longer panics if called on an
   invoice which set an explicit public key, rather than relying on public key
   recovery. This method is called from `payment_parameters_from_invoice` and
   `payment_parameters_from_variable_amount_invoice` (#4717).
 * Maliciously-crafted unpayable invoices which have overflowing feerates will
   no longer cause an `unwrap` failure panic (#4716).
 * `possiblyrandom` did not properly generate random data except when it was
   explicitly configured to. By default this means LDK is vulnerable to various
   HashDoS attacks (#4719).
 * `OMNameResolver` will no longer panic when looking up payment instructions
   which include unicode characters at the start of a TXT record (#4718).
 * `PrintableString` did not properly sanitize unicode format characters,
   allowing an attacker to corrupt the rendering of logs or UI (#4593, #4605).
 * RGS data is now limited in how large of a graph it is able to cause a client
   to store in memory. Note that RGS data is still considered a DoS vector in
   general and you should only use semi-trusted RGS data (#4713).
 * Counterparty-provided strings in failure messages are no longer logged in
   full, reducing the ability of such a counterparty to spam our logs (#4714).
 * Reading a corrupted `ChannelManager` or `ProbabilisticScorer` can no longer
   cause us to allocate large amounts of memory (#4712).

Thanks to Project Loupe for reporting most of the issues fixed in this release.
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this pull request Jun 23, 2026
v0.2.3 - Jun 18, 2026 - "Through the Loupe"

API Updates
===========

 * `DefaultMessageRouter` will now always generate blinded message paths that
   provide no privacy (where our node is the introduction node) for nodes with
   public channels. This works around an issue which will appear for any nodes
   with LND peers that enable onion messaging - such peers will refuse to
   forward BOLT 12 messages from unknown third parties, which most BOLT 12
   payers rely on today (lightningdevkit#4647).
 * Explicit `amount_msats` of 0 is rejected in BOLT 12 `Offer`s; `OfferBuilder`
   now maps 0-amounts to an amount of `None` (lightningdevkit#4324).

Bug Fixes
=========

 * `Features::supports_zero_conf` no longer clears the `ZeroConf` features and
   `Features::requires_zero_conf` now correctly reports required, rather than
   supported, status (lightningdevkit#4517).
 * If an MPP payment is claimed but `ChannelMonitorUpdate`s for some parts are
   still being completed asynchronously, further channel updates (e.g.
   forwarding another payment) are pending and the node restarts, the channel
   could have become stuck (lightningdevkit#4520).
 * The presence of unconfirmed transactions actually no longer causes
   `ElectrumSyncClient` to spuriously fail to sync (lightningdevkit#4590).
 * LSPS1, LSPS2, and LSPS5 persistence will no longer get stuck and refuse to
   persist again after a single failure from the KVStore (lightningdevkit#4597, lightningdevkit#4282).
 * Dropping the future returned by
   `OutputSweeper::regenerate_and_broadcast_spend_if_necessary` no longer
   results in future calls to the same method being spuriously ignored (lightningdevkit#4598).
 * Used async-receive offers are no longer refreshed on every timer tick once
   their refresh time is reached (lightningdevkit#4672).
 * `FilesystemStore::list_all_keys` will no longer fail if there are stale
   intermediate files lying around from a previous unclean shutdown (lightningdevkit#4618).
 * When forwarding an HTLC while in a blinded path with proportional fees over
   200%, LDK will no longer spuriously allow a forward that pays us 1 msat too
   little in fees (lightningdevkit#4697).
 * Fixed a rare case where a channel could get stuck on reconnect when using
   both async `ChannelMonitorUpdate` persistence and async signing (lightningdevkit#4684).
 * If we had exactly zero balance in a zero-fee-commitment channel, the
   counterparty was able to splice all of their balance out, violating the
   reserve requirements they'd otherwise be forced to keep (lightningdevkit#4580).
 * Providing an `Event::HTLCIntercepted` to the `LSPS2ServiceHandler` twice no
   longer results in spuriously opening a channel early (lightningdevkit#4656).
 * `Event::PaymentSent::fee_paid_msat` is no longer `None` in cases where
   `ChannelManager::abandon_payment` was called before the payment ultimately
   completes anyway (lightningdevkit#4651).
 * `AnchorDescriptor::previous_utxo` now provides the correct `script_pubkey`
   for non-zero-commitment-fee anchor channels (lightningdevkit#4669).
 * Syncing a `ChainMonitor` using the `Confirm` trait will no longer write some
   full `ChannelMonitor`s to disk several times per block (lightningdevkit#4544).
 * `OMDomainResolver` now correctly accounts for failed queries when rate
   limiting, ensuring we continue to respond to queries after failures (lightningdevkit#4591).
 * Calling `ChannelManager::send_payment_with_route` without a `route_params`
   and with an invalid `Route` will no longer panic (lightningdevkit#4707).
 * `LSPS2ServiceHandler::channel_open_failed` now correctly fails intercepted
   HTLCs rather than allowing them to fail just before expiry (lightningdevkit#4677).
 * `StaticInvoice::is_offer_expired` was corrected to check offer, rather than
   static invoice, expiry (lightningdevkit#4594).
 * `lightning-custom-message`'s handling of `peer_connected` events now ensures
   that sub-handlers will see a `peer_disconnected` event if a different
   sub-handler refused the connection by `Err`ing `peer_connected` (lightningdevkit#4595).
 * Replay protection for LSPS5 signatures now detects replays which are only
   different in the encoded signature's case (lightningdevkit#4701).
 * When `lightning-liquidity` is configured in the background processor, there
   is no longer a stream of `Persisting LiquidityManager...` log spam (lightningdevkit#4246).
 * Incomplete MPP keysend payments will no longer see their HTLCs held until
   expiry (lightningdevkit#4558).
 * `InvoiceRequestBuilder` will no longer accept a `quantity` of `0` for a
   BOLT 12 `Offer`, allowing any quantity up to a bound (lightningdevkit#4667).
 * `lightning-custom-message` handlers that return `Ok(None)` when asked to
   deserialize a message in their defined range no longer cause panics (lightningdevkit#4709).
 * Several spurious debug assertions were fixed (lightningdevkit#4537, lightningdevkit#4618, lightningdevkit#4026)

Security
========

0.2.3 fixes several underestimates of the anchor reserves required to ensure we
can reliably close channels, several denial-of-service vulnerabilities and a
sanitization issue.
 * `Bolt11Invoice::recover_payee_pub_key` no longer panics if called on an
   invoice which set an explicit public key, rather than relying on public key
   recovery. Note that this method is called from
   `PaymentParameters::from_bolt11_invoice` (lightningdevkit#4717).
 * Maliciously-crafted unpayable invoices which have overflowing feerates will
   no longer cause an `unwrap` failure panic (lightningdevkit#4716).
 * Parsing an `LSPSDateTime` which is before 1970 no longer panics. This is
   reachable when parsing messages from counterparties (lightningdevkit#4715).
 * `possiblyrandom` did not properly generate random data except when it was
   explicitly configured to. By default this means LDK is vulnerable to various
   HashDoS attacks (lightningdevkit#4719).
 * `OMNameResolver` will no longer panic when looking up payment instructions
   which include unicode characters at the start of a TXT record (lightningdevkit#4718).
 * When using the `anchor_channel_reserves` module to calculate reserves
   required to pay for fees when closing anchor channels, zero-fee-commitment
   channels were not considered. This could allow a counterparty to open many
   channels, leaving us unable to properly force-close (lightningdevkit#4592).
 * The `anchor_channel_reserves` module overestimated the value of `Utxo`s in
   the wallet by ignoring the `TxIn` cost to spend them (lightningdevkit#4670).
 * `PrintableString` did not properly sanitize unicode format characters,
   allowing an attacker to corrupt the rendering of logs or UI (lightningdevkit#4593, lightningdevkit#4605).
 * RGS data is now limited in how large of a graph it is able to cause a client
   to store in memory. Note that RGS data is still considered a DoS vector in
   general and you should only use semi-trusted RGS data (lightningdevkit#4713).
 * Counterparty-provided strings in failure messages are no longer logged in
   full, reducing the ability of such a counterparty to spam our logs (lightningdevkit#4714).
 * Reading a corrupted `ChannelManager` or `ProbabilisticScorer` can no longer
   cause us to allocate large amounts of memory (lightningdevkit#4712).

Thanks to Project Loupe for reporting most of the issues fixed in this release.

Conflicts resolved in:
 * lightning/src/chain/channelmonitor.rs
 * lightning/src/events/mod.rs
 * lightning/src/ln/channelmanager.rs
 * lightning/src/ln/mod.rs
 * lightning/src/ln/offers_tests.rs
 * lightning/src/ln/onion_utils.rs
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

4 participants